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The Communication Software Group joined the System Software Section as a result of the recent 
SDD reorganization. Hence, this and subsequent progress reports will be addressed to Bill Lynch. 

Planning and Administration 

Much of the past month has been consumed by Teak planning activities. Jim White, Victor 
Schwartz, and Yogen Dalai attended both the Internal and External Pilot Hearings held in Palo Alto 
on 12 and 23 January, respectively. In preparation for diese meetings, CS delivered to Hugh Lauer 
updated, prioritized communication task lists and developed for its own use work schedules for the 
coming six mondis. 

CommAmication Software began an acdve search for two high-caliber, networking-oriented people to 
fill its vacant OIS Communication slots. Updated personnel requisidons are now on file. 

Jim met on 9 January with other group managers to discuss with die architect the floor plan for the 
new SDD/ASD building at Hillview and Arastradero. Jim also worked widi Bill Lynch to establish 
a mail forwarding service between group members' Building 33 boxes and Building 34 offices. 

Jim was appointed chairman of a princops I/O interface working group consisting of Pitts Jarvis, 
Dave Redell, and Ed 1 aft, and advised by Butler Lampson. This group will meet twice a week and 
report its results at the 22 Febmary meeting of the Architecture Review Board. 

Jim helped Everett. Ncily organize a fruitful 19 January Palo Alto meeting on Mesa signalling 
conventions for Product Software. Several CSers attended and arc considering how they might 
modify their current error handling approaches to anticipate the guidelines that will eventually be 
established. 

OIS Communication 

Remote Procedure Call Package 

Since his dmc was largely occupied by planning acdvitics, Jim White made litUc juogrcss this 
mo!it]i on the IIPCP Functional Specification. A 12 January discussion widi Peter Bishop, however, 
suggested some possible improvements to RPCP's client interface and helped Peter understand how 
RPCP might be used by his transacUon system. 

File Transfer Package 

Jim White consulted regularly all month with Jay Israel on his convei-sion of Juniper to FfP 4.1. 
With both nie and mail servers Ruining as of 5 January, Jay is now looking at performance issues. 
Jay has made a number of suggesdons for minor FIT changes that will he rellected in a subsequent 
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release. However, Jim rejected Jay's request for implementation of tlie mail forwarding flmcdon, 
since it represents too much work and too little payoff for SDD. 

Jim helped Bmce Malasky and Jerry Morrison bring up Brownie under FTP 4.1. 

Inlernelwork Router 

Hal Murray has been in contact with Art Axelrod (WRC), who is bringing up a few new 
Internetwork Routers, and wiUi John Beeley (ASD), who is about to ship some more to ASD probe 
sites. 

Pup and OIS Communication Packages ■ 

Jim White and Yogen Dalai met with Ben Wegbreit, Doug Brotz, and Steve Butterfield on 4 
January to discuss ASD's market probe Pup communication requirements. Yogen's 29 December 
"Pups in Pilot" memo and his 19 December "Absolute vs. Relative Host Numbers" memo address 
some of the issues discussed at the meedng. Initiated by CS, the meedng yielded information about 
die applicadons ASD expects to mn on die DO. The quesUon of Pup/OISCP compatibility appears 
to be only the first of many compadbility problems ASD will face in trying to integrate OIS 
products with PARC research systems. 

Jim, Yogen, and Hal Murray began development of an SDD strategy for sadsfying ASD's now 
long-term needs for DO Pup comm.unicadon. Our tentative approach is to remove the Pup Package 
from Pilot, rather dian restaicture it to confonn to Pilot design principles, as initially planned. A 
subsequent memo by Jim will modvate this course of action. 

Peter Bishop, Charles Irby, Ted Linden, and Richard Moore set forth DataTalk's requirement for 
multicasting in their 2 January memo entitled "The Datatalk Requirement for Multicast". Yogen 
responded widi a 19 January memo entitled "Multicast in OISCP", which ouUines one possible 
technical approach but which also points out a number of architectural and administrative problems 
diat must be solved first. 

Yogen conUnued work on his "Pup Protocols and OISCP" memo, which will discuss die differences 
between the existing Pup protocol fiimily and die new OIS Communicadon Protocol. The memo 
will describe the advantages of the latter over the former in an attempt to demonstrate that the 
benefits of the new protocol outweigh the compatibility problem it creates. 

Yogen began redesign of the OIS Communicadon Package's buffer allocadon mechanism while Hal 
implemented a first-cut lOCB-format DO Ethernet driver, by means of which CS' DO EM is already 
forwardng packets from one Ediernct to another. Widi Dave Boggs (PARC), Hal is also working 
on an automatic boot file distribution mechanism. 

OIS Hardware 

Jim White and Yogen Dalai attended Network Analysis Corporation's 16 January El Segundo 
presentation to XliS Planning. NAC just completed a several-month analysis Of various local 
networking technologies, including the Xerox Wire. Jim, Yogen, and Ron Crane also discussed 
with Phil Arst on 17 January the feasibility and implicadons of markedng die Xerox Wire as a 
product.' ' ' 

Hal Murray worked with Roy Ogus and Ron Crane on the Edicrnet and Xerox Wire boards, 
microcode, and test program. The l^tiicrnet board is largely working, aldioiigh a, few too many 
packets are missed and an occasional bad packet arrives looking good. Ilie Xerox Wire board, on 
die other hand, suffers from more basic problems, missing far too many packets. Mai's test program 
drives up to direc l^thernet or Xerox Wire boards, sending and receiving on any combination of 
diem. 

The frequency widi which CS' DO EM is broken by static electricity has been significandy reduced 
by replacement of die keyboard. However, die machine is sdll suscepdblc to an occasional crash. 
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especially wlien the umbilical is connected. 

The six Ethernet transceivers and cables ordered tlirough SD Support on 29 November arrived. 

Gateway Functions 

Gateway Facility 

Larry Garlick described the Gateway Facility to Palo Alto and El Segundo SDD personnel in 
January 9 and 17 Crosstalks, respecdvely. 

While in El Segundo, Laixy and Victor Schwartz met widi Steven Abraham, Dan DeSantis, and Jim 
Reiley (PS) to discuss die Gateway Facility and its usage in Star. The results of the meeting are 
summarized in Steven's 18 January memo entitled "Minutes From Meeting on Gateway Software 
and Star" and in Larry's 24 January memo entitled "Addendum to Minutes From Meeting on 
Gateway Software and Star". Larry points out some possible problems in the Star user model in 
his 19 January memo entitled "Comments on Star User Interface to Communicating Foreign. 
Devices". 

Tlie El Segundo meedng revealed that the Gateway Facility will be without clients for at least six 
more months. The flill burden of testing and exercising that software, therefore, will necessarily fall 
upon Communication Software, while Product Software forfeits important early experience with 
gateway fimcdons and foreign devices. This is a potential problem area. Consistent with diis fact, 
however, formal release of Version 2.0 of the Gateway Software Functional Specification, originally 
slated for this month, will be deferred until later in die Teak development cycle. Bodi tlie Gateway 
Software Functional Specification and the Gateway Design Specification are currendy being 
circulated for review within Gateway Functions. The latter will include as an appendix Sarah- Ann's 
descripdon of die odicrwise undocumented Xerox 800 idiosyncrasies discovered during the 
debugging process. 

Victor responded to Linda Bcrgstcinsson's December progress report with a reminder that 
Communicauon Software is eager to learn of specific Star EDP requirements. At present, we have 
no direction from planning in diis area. 

Larry critiqued the ISO/TC97/SC16 report on Open Systems Interconnection, which attempts to 
define a comprehensive model for distributed systems. CS will look flirther at this and related 
documents as part of its ongoing international communication standards activities. 

RS232C Channel 

Victor Schwartz and Bill Daniclson approached convergence on a set of changes diat will make the 
channel interface sufficiently flexible to handle all planned microcode variants, as well as reasonable 
hardware changes. Sarah- Ann Bishop modi (led the X800 Driver to reflect the changes, enabling 
Victor and Bill to begin testing the new microcode on the 1)0. The RS232CTest program developed 
by Larry Garlick and for which Victor has now assumed responsibility is also being modified to 
track tlie changes. In addition, the Xerox 800 checksum machinery is now working properly and 
the X800 Driver's receive function has been designed and partially coded. 

Victor has had a number of useful interactions this mondi with Bob Bell (ASD), v/ho is attempting 
to implement tiic RS232C Chaimcl interface on Comml^roc hardware to support full BSC, including 
transparant data. Not surprisingly, Bob has found our current implcmciuation, which provides 
Xerox 800 support only, deficient in a number of respects. Victor and Bob arc dierefore negotiating 
changes to Uie interface so as to both accommodate ASlTs needs and maintain (as far as possible) a 
single standard interface. 

Victor succeeded in transferring files between the IBM System 6 and Uie IBM CMC II in both 
directions, masteiing. the art of printing and reading the CI*! communications log on the System 6 
disk in the process. The log revealed tiiat the machine had been improperly installed and a fix by 
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IBM enabled data transfers to proceed. Bill set up the CMC IFs send and receive magnetic card 
decks in preparation for the experiment. Meanwhile, Larry and Sarah-Ann worked to resolve 
problems encountered while sending to the Xerox 800. As a result, monitoring and logging code 
was added to tlie Frainer and the Gateway Transducer. 

RS-232-C Microcode 

Bill Danielson began looking into methods by which the various RS-232-C microcode variants might 
be loaded as needed at nm-time. The whole area of dynamic microcode loading remains ill-defined; 
Bill and Victor Schwartz plan to meet with Carol Hankins on this subject before she departs. 

Bill coded a bit synchronous microcode variant and tested it in simple loopback mode with a 
microcode driver. The synchronous microcode variants require external clocking, but a timer bug 
makes using such clocking difficult. Although Chuck Thackcr has fixed the bug on one DO, that 
machine will not run the currently available microcode versions for other reasons. Chuck indicates 
that a new PROM must be blown and Bill has formally requested, through Robert Kierr, diat this 
be done. Synchronous microcode variants cannot be tested through a modem until this work is 
performed. 

Gateway Hardware 

Victor Schwartz and Bill Danielson helped supply Bob Belleville with the information required to 
develop the DO MIOC board, contributing a requirements specification for the board's gateway (that 
is, RS-232-C and RS-366) hardware. The entire MIOC specification, which includes 
Communication Software's input, is fded on [Iris]<Schwartz>RSpecMIOC.Bravo. 

We still await installation, in Sarah-Ann Bishop's office, of the RJ-U jack requested on 1.5 
December. We are informed through Lee Anderson that its installation is imminent. Meanwhile, 
our Xerox 800 testing efforts are hampered. 

A Xerox 850 was ordered on 5 January. 

Next Month 
Sarah-Ann Bishop 

1. Complete coding and start debugging the X800 Driver receive function. 

2. Complete tlie Protocol Driver Documentation (with X800 specifics). 

3. Begin designing and coding gateway stream test programs for the Xerox 800. 

4. Complete debugging the X800 Protocol Driver. 

Yogen Dalai 

1. Complete memos currcndy in progress. 

2. Obtain a set ofbasclinc Pilot 2.0 performance measurements. 

3. Attempt to resolve the network numbers issue. 

4. With Hal, work out a first cut reorganization of the Pilot communication code. 
' 5. Work on the IS DislribulcclSysfcniArchilecture Spcci/Icalion. 

6. Make a first cut at the papers for SIGOPS. 

Bill Danielson 

1. Convert RS-232-C microcode to microcode version 2.1b. 

2. Try to put together an interim, «^//ac microcode loader. 

3. Meet with Carol llaiikins before she departs. 
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Larry Garlic k 

1. Test file transfer to and from the Xerox 800 mag tape via an Alto. 

2. Start integrating the RS232C Manager and OIS Transporter into Pilot. 

3. Submit Star Functional Specijkalion CRs re CFD property sheet parameters. 

4. Reevaluate error handling and logging in Gateway Software. 

Hal Murray 

1. Continue beating on the DO and the Xerox Wire. 

2. Produce a Nova/ Alto Gateway package with automatic boot file distribution. 

3. Begin converting tlie Pup Package to Mesa 5.0. 

4. Complete planning for tlie next 4-6 montlis. 

Victor Schwartz 

1. Resolve (modem?) problems relating to Alto/DO-to-Xerox 800 test program. 

2. Add missing features (e.g., break) to asynchronous channel implementation. 

3. Complete design and implementation of RS232C Channel interface changes. 

4. Add bit-synchronous support to RS232C Channel, 

5. Expand RS232CTest to include bit-synchronous tesdng. 

6. Continue involvement in Pilot/Teak planning activides. 

Jim White 

1. Further refine task list and work schedules for Teak. 

2. Prepare group work plans. 

3. Chair princops I/O interface working group. 

4. Help prepare the annual SDD technical review forXBS management. 

5. Prepare a memo motivating our decision to depilotize tlie Pup Package. 

6. Convert FIV 4.1 to Mesa 5.0 as an alpha tester. 

7. Beat the bushes for Arpanet aces. 

8. If possible, resume work on the RPCP Functional Specification. 



c: SDD/SS/CS 



